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FOREWORD 


This Indian Standard was adopted by the Bureau of Indian Standards, after the draft finalized by the Software and 
System Engineering Sectional Committee, had been approved by the Electronics and Information Technology 
Division Council. 


This standard defines set of core practices that are present in any Agile methodology. These practices are grouped 
in accordance with the process groups of IS 16124 : 2020 (identical to ISO/IEC/IEEE 12207 : 2017) as practices 
under agreement processes, practices under technical management processes, practices under technical processes 
and practices under organizational project-enabling processes. These practices enable the application of any Agile 
methodology in acquisition, supply, development, operation, maintenance and disposal of software systems, 
products and services. 


The Committee responsible for the formulation of this standard has reviewed the provisions of the International 
publications listed in Annex B and has decided that these may be used in conjunction with this standard till Indian 
Standards on these subjects are published. 


The composition of the Committee responsible for the formulation of this standard is given in Annex C. 
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INTRODUCTION 


0.1 Overview 


All software systems have a lifecycle, irrespective of whether it is established formally or not. A lifecycle is a 
set of distinguishable phases or stages that the software goes through from its conceptualization until it ceases to 
exist. Lifecycle models are often considered as a framework of processes and activities that serve as the baseline 
for understanding and communicating about the software system. Software systems typically passes through 
its lifecycle as the result of tasks being performed by organizations and people, by instantiating a framework of 
processes and activities for their respective contexts. IS 16124 : 2020 (Identical to ISO/IEC/IEEE 12207 : 2017) 
standard provides requirements related to a common process framework for describing the life cycle of software 
systems. These processes can be used by any organization to construct life cycle models for their product and 
service offerings. 


The Agile way of software development has become a necessity due to ever changing nature of business 
requirements that defines the software. The Agile Manifesto and related values and principles have served as 
reference for agile practices across many organizations. However, there is no uniform adoption of agile practices 
in the industry. Different organizations exhibit different levels of maturity and diverse ways of interpreting, 
adopting, and implementing these practices. The Agile practices discussed in this document offer a lightweight, 
adaptive, and collaborative development approach based on empiricism with the focus on rapid business value 
delivery. This standard enlists core practices, which should be part of any Agile methodology. 


Requirements of this document are marked using the verb “shall”. Recommendations are marked using the verb 
“should”. Permissions are marked using the verb “may”. 
0.2 Need for the Standard 
Standardization of agile practices is essential for the following reasons: 
a) For Vendors — It provides a list of core practices. 


b) For Acquirers — It provides a basis to differentiate the maturity of the vendor by assessing against these 
practices. 


c) For Both Parties — It provides a basis for agreement. 


Standardization in this area will be very useful for software vendors, software acquirers, software service 
providers, large delivery and maintenance projects, system integration engagements having software components 
and in general, the entire software community. 


0.3 Purpose 


The purpose of the standard is to document the core practices, which Agile projects must demonstrate. Acquirers, 
suppliers, developers, integrations, operators, maintainers, managers, quality assurers, and users of software 
systems, products and services, for a range of situations and contexts can use this standard. 
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Indian Standard 


SOFTWARE AND SYSTEMS 
ENGINEERING — CORE AGILE PRACTICES 


1 SCOPE 


This standard defines set of core practices that are 
present in any Agile methodology. These practices 
are grouped in accordance with the process groups of 
IS 16124 : 2020 (identical to ISO/IEC/EEE 12207 : 2017) 
as practices under agreement processes, practices 
under technical management processes, practices under 
technical processes and practices under organizational 
project-enabling processes. These practices enable the 
application of any Agile methodology in acquisition, 
supply, development, operation, maintenance and 
disposal of software systems, products and services. 


The practices defined in this standard are applicable for 
a single Agile project, as well as for an organization 
performing multiple Agile projects. These practices 
are applicable throughout the lifecycle of software 
systems, products and services. 


2 REFERENCES 


The standards listed in Annex A and Annex B contains 
provisions which, through reference in this text, 
constitute provisions of this standard. At the time 
of publication, the editions indicated were valid. 
All standards are subject to revision and parties to 
agreement based on this standard are encouraged to 
investigate the possibility of applying the most recent 
editions of the standards indicated in Annex A and 
Annex B. 


3 TERMINOLOGY 


For the purpose of this standard the following terms 
and definitions shall apply. 


3.1 Acceptance Criteria — Adoption of Agile values, 
principles and practices in the way of working. 


3.2 Agile Adoption — Change in process to agile 
principles. 


3.3 Agile — Iterative and incremental approach to 
software delivery. 


3.4 Product Backlog — Prioritized listing of product 
requirements. 


3.5 Agile Workspace — Collaborative workspaces 
conducive to agile ways of working. 


3.6 Continuous Improvement — Method to identify 
opportunities for streamlining work and reducing 
waste. 


3.7 Cross-team Synchronization — Method of 
coordination between team and other collaborators. 


3.8 Definition of Ready — Working agreement on the 
product backlog item’s readiness criteria. 


3.9 Definition of Done — Working agreement on the 
delivery readiness criteria. 


3.10 Iteration Retrospective — meeting where the 
team explores the results of the previous iteration to 
improve their practice. 


3.11 Release Backlog — subset of product backlog 
planned for the next release. 


3.12 User Story — Brief description of required 
functionality describing the stakeholder roles, goals, 
benefits, and motivation. 

NOTE — Larger user stories that are at an earlier stage of 


product backlog refinement are sometimes referred to as epics 
and/or features. 


For example — The scaled Agile Framework describes a 
3 level hierarchical requirement model. Epics can be 
subdivided into features. Features can be subdivided in user 
stories (see ISO/IEC/IEEE 26515 : 2018). 


3.13 Working Agreement — Statement of the working 
relationship in an agile environment. 


4 CONCEPTUAL FOUNDATIONS 


4.1 Lifecycle Processes 


Every software product or service has a lifecycle 
IS 16124 : 2020 (identical to ISO/IEC/IEEE 12207 : 2017) 
describes this life-cycle as an abstract functional 
model that represents the conceptualization of the 
needs, realization by addressing the needs, subsequent 
utilization after realization, evolution based on change 
in environment or evolving needs and retiring or 
disposing the software product or service at the end of 
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its useful life. IS 16124 : 2020 proposes 4 interacting 
process groups: 


a) Agreement processes, 

b) Organizational project-enabling processes, 
c) Technical management processes, and 

d) Technical processes. 


Covering the activities that are typically performed 
during the software systems lifecycle. 


The agreement processes aid organizations to agree on 
the responsibilities of the different functions related 
to software during its conceptualization, realization, 
utilization, evolution, and subsequent disposal. The 
organizational project-enabling processes enable an 
organization to acquire and supply software through the 
initiation, support, and control of projects. The technical 
management processes aid organizations to manage 
resources and assets provided by the organization to 
meet the agreements and other organizational 
commitments. The technical processes aid organizations 
to understand requirements, transform them into 
appropriate software products or services, reproduce 
software as and when needed, utilize the software in 
different environments, sustain the software till they 
are decommissioned, and retire or dispose the software 
at the end of its useful life. 


4.2 Agile Practices 


This standard provides agile practices that can be 
utilized while implementing IS 16124 : 2020 in an 
agile way in organizations. These practices are grouped 
into four practice groups and relevant subgroups 
in alignment with the process groups as outlined in 
IS 16124 : 2020. Each of the practices within those 
groups and subgroups are described in terms of its 
purpose, goals and desired outcomes. The practices 
described in this standard are not intended to preclude 
or discourage the use of additional practices that 
organizations may find useful. 


The practices in this standard can be used by any 
organization fully or partially while using, creating, or 
supplying a software product or service. The sequence 
that the practices are presented in, does not imply 
any prescriptive order in their use. Concurrent use of 
practices might exist in a project and between projects. 


4.3 Criteria for Practices 


The determination of agile practices is based upon 
three basic principles: 


a) Each agile practice has strong relationships to its 
outcomes; 

b) The dependencies between the practices are 
reduced to a minimum; and 

c) Apractice can be adopted by a single organization 
or project. 


4.4 Description of Practices 


Each practice is described in terms of the following 
attributes: 


a) The title summarizes the practice; 


b) The overview describes the purpose and goals of 
performing the practice; and 


c) The outcomes describe the observable results 
that are expected on successful execution of the 
practice. 


5 AGILE PRACTICES 


5.1 Practices under Agreement Processes 


These practices provide considerations that should 
be applied while defining contracts in agile projects. 
They should enable both acquirers and suppliers to 
realize value and support business strategies for their 
organizations. 


This clause defines the requirements for the 
establishment of agreements with organizational 
entities external and internal to the organization. 


The practices under agreement processes consist of the 
following: 


a) Contracting Practice — Used by organizations 
towards building work agreements. 


b) Practices under Acquisition Processes — Used by 
the acquirer to obtain a product or service. 


c) Practices under Supply Processes — Used by a 
supplier to supply a product or service. 


5.1.1 Contracting Practice 


The purpose of the contracting practice is to establish 
the working agreement between two parties involved in 
an agile endeavour. The contracting practice provides 
for establishing a work agreement based on specific 
terms, conditions, capacity, and deliverables. Typical 
things that are detailed out and agreed upon are: number 
of agile teams, model experience profiles, technology 
focused agile teams, functional specialists, delivery 
capability, payment intervals, amount to be paid, mode 
of payment, deviation processes to be followed for any 
variation, change in demand, delivery quality details as 
required, scope of delivery, range of services expected, 
small changes and enhancements and so on. 


5.1.1.1 Outcomes 


As a result of the successful implementation of the 
contracting practice: 


a) Statement of work is established; 

b) Contract agreement is established; 

c) Concept of operations is established; 

d) Service-level agreements are established; and 

e) Terms and conditions of engagement is established. 


5.1.2 Practices under Acquisition Process 


The purpose of this practice is to obtain a product or 
service in accordance with the acquirer’s requirements 
and in alignment with agile values and principles. 
The acquirer should define a strategy for how the 
acquisition should be conducted and prepare a request 
for the supply of the product or service in accordance 
with agile requirement management practices. 
NOTE — IS 16124 Systems and software engineering — 
Software life cycle processes contains detailed activities 
that describe preparation for the acquisition, advertising the 
application, supplier selection, establishing, maintaining, 
monitoring the contract and acceptance of the product or 
service. 


5.1.2.1 Outcomes 


As a result of the successful implementation of this 
practice: 


a) One or more acquisition strategies are identified; 
b) One or more analysis is performed; 


c) One or more business cases for acquisition are 
established; and 


d) Agile implementation approach is identified. 


NOTE — These outcomes are in addition to the results of 
the successful implementation of the IS 16124 — Systems 
and software engineering — Software life cycle processes — 
Acquisition process. 


5.1.3 Practices under Supply Process 


The purpose of this practice is to provide a product or 
service to the acquirer in accordance with the acquirer’s 
requirements and in alignment with agile values and 
principles. The supplier should define a supply strategy 
towards identifying potential acquirers for the product 
or service and responding to requests for supply of the 
product or service from acquirers. 
NOTE — IS 16124 : 2020 contains detailed activities that 
describe preparation for the supply, responding to a request 
for supply of product or services, establishing, maintaining, 
executing the contract and, delivering and supporting the 
product or service. 


5.1.3.1 Outcomes 


As a result of the successful implementation of this 
practice: 

a) One or more supplier strategies are identified; 

b) One or more analysis is performed; 


c) One or more business cases for supply are 
established; and 
d) Agile implementation approach is identified. 


NOTE — These outcomes are in addition to the results of 
the successful implementation of the IS 16124 : 2020 Supply 
process. 
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5.2 Practices under 
Project-Enabling Processes 


Organizational 


These practices establish the environment in which 
the agile projects are conducted. They apply outside 
the span of a project’s life cycle as well as during a 
project’s lifespan. They are typically concerned with 
the provision and deployment of resources and assets 
towards ensuring the project meets the need and 
expectations of the stakeholders and achieves expected 
business outcomes. 


This clause defines the requirements for the 
establishment of practices under organizational 
project-enabling processes. These practices ensure 
the organization’s capability to provide resources 
and infrastructure necessary to support agile projects 
and help ensure the satisfaction of the organizational 
objectives and established contracts. These practices 
consist of Agile team management practice — used by 
organization to create the right environment for teams. 

NOTE — These practices should be considered as an extension 


to the organizational project-enabling processes described in 
IS 16124 : 2020. 


5.2.1 Agile Team Management Practices 


Agile team management practices are used to harness 
the abundance of global talent and optimize economics. 


The agile team management practices consist of the 
following: 
a) Cross Functional Team Practice — Used to 
enhance value delivery. 


b) Feature Team Practice — Used to optimize 
delivery of business value. 


c) Component Team Practice — Used to develop 
components. 

d) Co-located Team Practice — Used to optimize 
collaboration and cooperation. 


e) Distributed Team Practice — Used to optimize 
resource availability and economics. 


f) Shared Code Practice — 
dependencies within teams. 


Used to reduce 


5.2.1.1 Cross functional team practice 


The purpose of the cross functional team practice is 
to define the common working goal for a team with 
different functional expertise to collaborate in an 
efficient manner. The cross functional team practice 
provides for establishing an amicable collaborative 
atmosphere which can deal effectively with 
cross-functional dependencies. All the skills that are 
necessary to deliver a successful incremental product 
is available within the team. This allows for a less 
structured, more interactive, highly performant team 
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that are self-directed and can leverage the experience 
and variety in the team to make better decisions. 
Typical things that are detailed out and agreed upon 
are: shared responsibilities, roles, skillsets, consensus 
criteria, prioritization criteria, goals and objectives, 
resources and logistics, and so on. 


5.2.1.1.1 Outcomes 


As a result of the successful implementation of the 
cross functional team practice: 


a) Common working goals, working criteria and 
objectives are established; 


b) Working agreement, required resources and 
logistics are established; 


c) Agile team with enhanced ability to self-organize 
is established; 


d) External dependencies are reduced; 
e) Value delivery is accelerated; and 


f) Trust and accountability within the team is 
increased. 


5.2.1.2 Feature team practice 


The purpose of the feature team practice is to define 
a set of end-to-end features and the order in which 
they need to be delivered for a cross-functional, 
cross-component, long-lived team that leads to a 
potentially shippable product increment. The feature 
team practice provides for establishing an end-to-end 
feature ownership and delivery mechanism which can 
deal effectively with shipping a product increment on 
schedule. All the skills that are necessary to deliver a 
successful incremental product is available within the 
team. Further, the team should focus on delivering 
one end-to-end customer centric complete feature 
at a time. This allows for a focused, less structured, 
more interactive, highly performant team that are self- 
directed and can leverage the expertise in the team to 
deliver high quality products. Typical things that are 
detailed out and agreed upon are: feature set, sequence 
of delivering the features, shared responsibilities, roles, 
skillsets, consensus criteria, prioritization criteria, goals 
and objectives, resources, and logistics, and so on. 


5.2.1.2.1 Outcomes 


As a result of the successful implementation of the 
feature team practice: 


a) Set of end to end features and the order of delivery 
is established; 

b) Common working goals, working criteria and 
objectives are established; 

c) Working agreement, required resources and 
logistics are established; 

d) Agile team with enhanced ability to deliver 
end-to-end features is setup; 


e) Customer-centricity of the product is increased; 
and 


f) Incremental product is shipped. 


5.2.1.3 Component team practice 


The purpose of the component team practice is to 
define a set of components that are owned, developed, 
maintained, and delivered by a focused component 
development team which contributes to solutions. The 
component team practice provides for establishing 
an end-to-end component ownership and delivery 
mechanism which can deal effectively with shipping 
a customer-valuable solution. All the skills that are 
necessary to develop, maintain and deliver these 
components are available within the team. This allows 
for a focused, interactive, tightly coupled team that are 
self-directed and can leverage the expertise in the team 
to deliver high quality reusable components. Typical 
things that are detailed out and agreed upon are: set 
of components, roles, responsibilities, architecture 
robustness, goals and objectives, resources and 
logistics, and so on. 


5.2.1.3.1 Outcomes 


As a result of the successful implementation of the 
component team practice: 


a) Agile team with enhanced ability to deliver shared 
components is setup; 


b) Working agreement, necessary resources and 
logistics are established; 


c) Common working goals, criteria and objectives 
are established; and 


d) Solutions are delivered. 


5.2.1.4 Co-located team practice 


The purpose of the co-located team practice is to 
define strategies, resources and goals to be achieved 
in order to achieve high productivity, working 
relationships, efficient and effective communication, 
high collaboration and strong team bonding. The 
co-located team practice provides for establishing a 
physically co-located team-based delivery mechanism 
with high productivity, high collaboration, strong team 
bonding, efficient and effective communication. The 
goals and objectives of the team are well understood 
and all the skills that are necessary to achieve the goals 
and objectives are co-located together. This allows 
for a focused, interactive, productive, tightly coupled 
team that are self-directed and can deliver at high 
rates. Typical things that are detailed out and agreed 
upon are: location, roles, responsibilities, knowledge 
sharing, escalation matrix, decision guidelines, goals 
and objectives, resources, and logistics, and so on. 


5.2.1.4.1 Outcomes 


As a result of the successful implementation of the 
co-located team practice: 


a) Highly productive agile team with faster 
decision-making capability based outofa common 
location is setup; 


b) Working agreement, necessary resources, location 
and logistics are established; 


c) Communication, Collaboration, cooperation and 
working relationships within the team is enhanced; 

d) A sense of belonging and being part of community 
is developed; and 

e) Conflict resolution and knowledge 
becomes swift. 


sharing 


5.2.1.5 Distributed team practice 


The purpose of the distributed team practice is to 
define strategies, resources, and goals to be achieved 
to deal with domain complexity, organizational 
scale-up, global reach, technical complexity, quicker 
time to market, and increasing production costs. The 
distributed team practice provides for establishing 
a physically geographically distributed team-based 
delivery mechanism that scale-up with less investment, 
deals with technical and domain complexity, deals 
with customers spread across different geographies, 
and reach geographically distributed talents with 
requisite skills. Communication and collaboration 
occur using virtual spaces which allows a team located 
geographically at different locations to come together 
for delivering a solution. Typical things that are detailed 
out and agreed upon are: communication channels, 
roles, responsibilities, workflow, delivery schedules, 
decision guidelines, goals and objectives, resources, 
and so on. 


5.2.1.5.1 Outcomes 


As a result of the successful implementation of the 
distributed team practice: 


a) Ability to leverage global talent is established; 

b) Workflow, delivery schedules, decision guidelines 
and working agreement is established; 

c) Virtual communication, 
cooperation is established; 


collaboration and 


d) Team diversity and collective knowledge is 
enhanced; 


e) Superior product or solution is delivered; and 
f) Distributed team is setup. 


5.2.1.6 Shared code practice 


The purpose of the shared code practice is to define 
strategies, resources, and goals to own the deliverable 
in its entirety and to reduce dependencies within the 
organization and provide an environment to enhance 
creativity and innovation across the board. This practice 
is also called as the collective ownership practice. The 
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shared code practice provides for cooperative ownership 
and collective responsibility of the deliverables by all 
the members of the team, encourages contribution 
of new ideas to all segments of the deliverables, 
focuses on creative problem solving, and establishes 
an explicit convention that every team member can 
own, create and update the deliverables. Typical things 
that are detailed out and agreed upon are: ownership 
tokens, communication channels, acceptance criteria, 
roles, responsibilities, delivery schedules, decision 
guidelines, goals and objectives, and so on. 


5.2.1.6.1 Outcomes 


As a result of the successful implementation of the 
collective ownership team practice: 


a) Ability to leverage new ideas is established; 


b) Ownership tokens and working agreements are 
established; 

c) Communication channels, decision and design 
guidelines are established; 


d) Ownership and responsibility towards deliverables 
are increased; 


e) Collaboration, 
improved; and 


cooperation, team-spirit is 


f) Superior product or solution is delivered. 


5.3 Practices under Technical 


Processes 


Management 


These practices are concerned with managing the 
resources and assets towards ensuring the project 
meets the needs and expectations of the stakeholders 
and achieves expected business outcomes. These 
practices are used to establish and perform technical 
plans for the project and assess the progress towards 
expected business outcomes. This sub-clause defines 
the requirements for the establishment of practices 
under technical management processes. These practices 
relate to the technical effort of projects, to planning, 
synchronizing and governance. These practices are 
used in tandem with practices under technical processes 
to achieve the desired solution attributes. The practices 
under technical management processes consist of the 
following: 


a) Agile Planning and Synchronization Practices — 
Used to plan and synchronize agile projects and 
execution. 

b) Agile Governance Practices — Used to govern 
agile projects and execution. 

NOTES 


1 Technical management is ‘the application of technical 
and administrative resources to plan, organize and control 
engineering functions’ (see ISO/IEC/IEEE 24765 : 2017). 


2 These practices should be considered as an extension to the 
technical management processes described in IS 16124 : 2020. 
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5.3.1 Agile Planning and Synchronization Practices 


The Agile planning and synchronization practices are 
used by an organization to produce and coordinate 
effective and workable plans that are adaptive to the 
evolving customer needs and emerging conditions. 
They are applied in accordance with the various 
planning horizons. 


The agile planning and synchronization practices 
consists of the following: 


a) Cadence practice, 

b) Release planning practice, 

c) Deployment planning practice, 

d) Iteration planning practice, 

e) Synchronized iterations practice, 

f) Daily synchronization meeting practice, 

g) Cross team synchronization meeting practice, 

h) Product owner synchronization meeting practice, 
j) Value stream mapping practice, and 

k) Limiting work in progress practice. 


5.3.1.1 Cadence practice 


The purpose of the cadence practice is to establish a 
predictable schedule around events and activities. One 
such capability is the length of the development cycle 
and related activities and events leading to the capacity 
of predicting project outcomes. The cadence practice 
provides for establishing a sequence of repeatable 
time-bound activities and events which leads to 
a predictable, synchronized rhythm of product 
development with appropriate overlaps. All the other 
down-stream activities depend on this rhythm thereby 
enabling the agile project team to know what they are 
doing and when will the work get done. This enables 
the team to make reliable commitments on their 
deliverables as the team obtains a fair idea of their 
capability and capacity from the cadence. There are 
many factors that impact the selection of the cadence: 
criticality, risk, release frequency, success criteria, 
priorities, type of project, and so on. Cadence is used in 
iteration-based development approaches like iteration 
planning, iteration review, iteration retrospective, and 
so on. 


5.3.1.1.1 Outcomes 


As a result of the successful implementation of the 
cadence practice: 


a) Iteration cadence and agile events cadence are 
established; 


b) Delivery schedules and communication plans are 
updated; 
c) Risk related to activities and events are reduced; 


d) Synchronization and Queue management is 
improved; 


e) Dependencies are planned appropriately; and 
f) Project outcomes are predictable. 


5.3.1.2 Release planning practice 


The purpose of the release planning practice is to 
establish the right business and functional goals for 
the subsequent release and to assert the ability and 
feasibility of meeting the goals. The release planning 
practice provides for establishing the delivery goals, 
priorities, delivery ownership while considering the 
uncertainty, intangibility, and flexible nature of software 
development. Typical things that are considered are: 
features, user stories, AS IS and TO BE scenarios 
from multiple perspectives, functional and technical 
dependencies, technical debt, key milestones, iteration 
length, number of iterations, iteration frequency, 
estimates, release schedule, team size, and so on. 


5.3.1.2.1 Outcomes 
As a result of the successful implementation of the 
release planning practice: 
a) Release vision, release plan and release schedule 
are established; 
b) Product backlog and impediment register are 
updated; 


c) Technical debt, functional 
dependencies are established; 


and technical 


d) Prioritised business features are deployed in the 
subsequent release; 


e) Dependencies and mitigation plans are established; 
f) Team composition and configuration is established; 
g) Team is committed to the release plan; 


h) Delivery goals, ownership and priorities are 
established; and 


j) Acceptable and feasible release plan is established. 


5.3.1.3 Deployment planning practice 


The purpose of the deployment planning practice is 
to establish the right systematic, repeatable approach 
for transitioning the developed software into the target 
production environment. The deployment planning 
practice provides for technically defining and governing 
specific activities for release management and artefacts 
management as part of deployment. Typical things 
that are considered include: target schema, migration 
plan, release plan, customization plan, roll-out plan, 
configuration plan, business rule configurations, 
workflow configuration, build and deployment plan, 
deployment strategy, and so on. 


5.3.1.3.1 Outcomes 


As a result of the successful implementation of the 
deployment planning practice: 


a) Release plan and schedule, migration plan and 
procedures, recovery plan and schedule are 
established; 


b) Solution is deployed in the target environment; 


c) All released functions, services and capabilities 
are available; 


d) Team informed and engaged; and 
e) Traceability is established. 


5.3.1.4 Iteration planning practice 


The purpose of the iteration planning practice is to 
establish the delivery goals and related commitments 
for the subsequent iteration. The iteration planning 
practice helps in establishing a sensible commitment 
at the beginning of each iteration by determining the 
value that can be created by delivering high priority 
features. Typical things that are considered include: 
prioritized user stories, team backlog, incremental 
value, definition ofreadiness, dependencies, acceptance 
criteria, capability and capacity of the team, velocity 
and related estimates, design approach, and so on. 


5.3.1.4.1 Outcomes 


As a result of the successful implementation of the 
iteration planning practice: 


a) Iteration goals and 


established; 


b) Acceptance criteria, estimates, risk register and 
product backlog are updated; 


iteration backlog are 


c) Team commitment towards the iteration goal is 
established; 


d) Shared understanding between the development 
team and product owner is established; and 


e) Predictability of project outcomes is enhanced. 


5.3.1.5 Synchronized iteration practice 


The purpose of the synchronized iteration practice is to 
establish a common cadence at which all the iterations 
are initiated, performed, or terminated in a project 
across multiple agile teams. The synchronized iteration 
practice provides for establishing a common cadence 
across multiple agile teams in a project. The iterations 
can start or stop at around the same schedule or the 
respective durations can also be similar. Typical things 
that are considered include: Release plans, delivery 
schedules, domain and technical dependencies, 
acceptance criteria, capability and capacity of the 
team, velocity and related estimates, value delivery, 
integration constraints, and so on. 


5.3.1.5.1 Outcomes 


As a result of the successful implementation of the 
synchronized iteration practice: 


a) Iteration schedule and duration are established; 


b) Dependency management between agile teams is 
improved; 


c) Application and system integration are improved; 
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d) Collaboration and alignment between agile teams 
is improved; and 


e) Complete integrated solution released on schedule. 


5.3.1.6 Daily synchronization meeting practice 


The purpose of the daily synchronization meeting 
practice is to facilitate the progress of the agile team 
towards achieving the iteration goals and commitments 
by effectively dealing with risks, dependencies, 
impediments, related information, and alignment. The 
daily synchronization meeting practice provides ways 
and means for establishing a fundamental change in 
how responsibilities are met by the team; improving 
the alignment within the team and providing requisite 
information pertaining to the progress towards achieving 
the goals. Typical things that are considered include: 
status updates, activities performed, impediments, 
alignment issues, progress updates, and so on. 

NOTE — The daily synchronization meeting is commonly 


referred to as the “Daily scrum” or “Daily standup” when using 
the scrum framework. 


5.3.1.6.1 Outcomes 


As a result of the successful implementation of the 
daily synchronization meeting practice: 


a) Team task board and iteration goals are updated; 


b) Product backlog, impediments and risk register 


are updated; 
c) Alignment towards the 


improved; 


iteration goals are 


d) Dependencies and alignment issues are made 
visible; 

e) Collaboration and alignment between agile team 
members is improved; and 


f) Visible progress made towards achieving the 
iteration goals. 


5.3.1.7 Cross team synchronization meeting practice 


The purpose of the cross-team synchronization meeting 
practice is to facilitate the progress of multiple agile 
teams towards achieving the collective release goal, 
team iteration goals and commitments by effectively 
dealing with risks, dependencies, impediments, 
related information and alignment. The cross-team 
synchronization meeting practice provides ways and 
means for establishing a fundamental change in how 
responsibilities are met by different teams; improving 
the alignment between the different teams and providing 
requisite information pertaining to the progress 
towards achieving the release goals. Typical things 
that are considered include: cross-team status updates, 
cross-team impediments, cross-team alignment issues, 
cross-team progress updates, cross-team activities 
performed, and so on. 

NOTE — The cross team synchronization meeting is also 

referred to as the “Scrum of Scrums”, when using the scrum 

framework. 
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5.3.1.7.1 Outcomes 


As a result of the successful implementation of the 
cross-team synchronization meeting practice: 


a) Product backlog, iteration goals and release goals 
are updated; 


b) Impediments and risk register are updated; 
c) Alignment towards the release goals are improved; 


d) Cross-team dependencies and impediments are 
made visible; 


e) Cross-team alignment issues are made visible; 
f) Cross-team dependencies are addressed; 


g) Collaboration and alignment between multiple 
agile teams is improved; 


h) Visible progress made towards achieving the 
release goals; and 


j) Individual team plans, iteration goals are updated. 


5.3.1.8 Product 
practice 


owner synchronization meeting 


The purpose of the product-owner synchronization 
meeting practice is to facilitate the progress of agile 
releases towards achieving the program increment 
by effectively dealing with risks, dependencies, 
impediments, related information, and alignment. 
The product owner synchronization meeting practice 
provides ways and means for establishing a fundamental 
change in how responsibilities are met by providing 
visibility into progress and impediments. Typical 
things that are considered include: milestones, program 
increment objectives, internal dependencies among the 
teams, alignment issues, progress updates, activities 
performed, scope adjustment, program backlogs, and 
so on. 


5.3.1.8.1 Outcomes 


As a result of the successful implementation of the 
product owner synchronization meeting practice: 


a) Program backlogs, program goals and release 
goals are updated; 


b) Alignment towards the program increment goals 
are improved; 


c) Program impediments are resolved and made 
visible; 

d) Program alignment issues are made visible; 

e) Program dependencies are addressed; 


f) Visible progress made towards achieving the 
program goals; and 


g) Business priorities are aligned, and status updated. 
5.3.1.9 Value stream mapping practice 


The purpose of value stream mapping practice is to 
establish ways and means for analysing, improving the 


flow of information, reducing and eliminating waste 
by discovering the root causes and sources of waste. 
The value stream mapping practice provides ways and 
means to analyse the flow of information, people and 
resources required to deliver a software by identifying 
and eliminating process waste thereby increasing 
efficiency, throughput, and effectiveness. Typical 
things that are considered include, product backlog, 
deliverables, deliverable qualities, business value, 
delays, waste, constraints, assumptions, information 
flows, activities, processes, inventories, non-value 
adding activities, alternative flows, and so on. 


5.3.1.9.1 Outcomes 


As a result of the successful implementation of the 
value stream mapping practice: 


a) Product backlogs are updated; 

b) Processes are optimized; 

c) Information flows are established; 

d) Lead times are improved; 

e) Wait times are shortened; 

f) Handoffs are reduced; 

g) Waste reduced or eliminated; 

h) Non-value adding activities eliminated; and 
j) Foundational view of business developed. 


5.3.1.10 Limiting work in progress practice 


The purpose of limiting work in progress practice is to 
establish ways and means for identifying inefficiencies 
and bottlenecks that potentially impact an agile team’s 
ability to meet their goals and increase the throughput. 
The limiting work in progress practice provides ways and 
means to identify and eliminate inefficiencies, remove 
bottlenecks, reduce risks, optimize work capacity, 
establish optimal pace of work, thereby improving the 
ability of the team to meet the release goals, focus the 
team’s effort and improve throughput. Typical things 
that are considered include: waste, bottlenecks, delays, 
inefficiencies, velocity, iteration goals, release goals, 
release activities, team capability and capacity, key 
performance indicators, prioritizations, and so on. 


5.3.1.10.1 Outcomes 


As a result of the successful implementation of the 
limiting work in progress practice: 


a) Delivery maturity and 
achieved; 


release certainty is 


b) Continuous improvement is established; 

c) Throughput is increased; 

d) Inefficiencies and bottlenecks are reduced; 
e) Productivity and effectiveness are increased; 
f) Capacity management is improved; and 

g) Value delivery is enhanced. 


5.3.2 Agile Governance Practices 


The Agile governance practices are used to establish 
and maintain oversight to ensure that effective and 
workable plans are adapted, program and iteration risks 
are handled effectively, releases deliver the intended 
features and capabilities, programs are aligned towards 
organizational and business goals, and the program 
operates within the establish constraints. 


The agile governance practices consist ofthe following: 
a) Release review practice, 
b) Iteration review practice, 
c) Team retrospective practice, 
d) Program retrospective practice, 
e) Metrics governance practice, 
f) Technical debt governance practice, 
g) Program Board governance practice, 
h) Agile adoption maturity governance practice, 
j) Visual management practic,e 
k) Gemba practice, and 
m) Distributed agile governance practice. 


5.3.2.1 Release review practice 


The purpose of release review practice is to validate the 
product increment and verify if the product increment 
is ready for release. The release review practice 
provides for verification and validation of the product 
increment. Typical things that are considered include: 
state of confidence, changes to feature definitions, 
changes to user stories, differences in effort estimates, 
progress visibility, milestones, key performance 
indicators, risks, product quality, value adds, potential 
ROI impact, potential business value, product backlog, 
release vision, release goals, and so on. 


5.3.2.1.1 Outcomes 


As a result of the successful implementation of the 
release review practice: 


a) Improvement backlog is updated; 

b) Corrective actions are established; 

c) Continuous improvement areas are established; 
d) Effectiveness and efficiency is improved; and 
e) Business needs and future releases are aligned. 


5.3.2.2 Iteration review practice 


The purpose of iteration review practice is to evaluate 
the iteration progress and determine any corrective 
actions. The iteration review practice provides for 
verification and validation of the iteration progress. 
Typical things that are considered include: product 
backlog, number of user stories addressed, number 
of features incorporated, differences in effort 
estimates, velocity, progress visibility, milestones, key 
performance indicators, risks, iteration goals, iteration 
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backlog, feedback, dependencies, impediments, 
alignment issues, iteration schedule, and so on. 


NOTE — The iteration review practice is also referred to as the 
“Sprint Review”, when using the scrum framework 


5.3.2.2.1 Outcomes 


As a result of the successful implementation of the 
iteration review practice: 


a) Product backlog updated; 


b) Definition of Done and Definition of Ready 
updated; 


c) Corrective actions are established; 
d) Continuous improvement areas are established; 
e) Effectiveness and efficiency are improved; and 


f) Iteration alignment is improved. 


5.3.2.3 Team retrospective practice 


The purpose of team retrospective practice is to 
inspect current way of working with respect to people, 
processes, resources, tools, methods, and technologies 
and establish actions for improvement. The team 
retrospective practice provides for self-reflection and 
causal analysis on a completed iteration and establishes 
improvements and corrective actions on the way 
forward. Typical things that are considered include, 
past events, past situations, problematic scenarios, 
milestones, opinions, ideas, concerns, iteration backlog, 
product backlog, activities performed, impediments 
dealt, success stories, issues addressed, risks mitigated, 
priorities, accomplishments, constraints, assumptions, 
release goals, release schedule, and so on. 


NOTE — The team retrospective practice is also referred to as 
the “Sprint Retrospective”, when using the scrum framework. 


5.3.2.3.1 Outcomes 


As a result of the successful implementation of the 
team retrospective practice: 


a) Iteration and release plans are established; 


b) Product backlog and improvement backlog are 
updated; 

c) Definition of ready and Definition of done is 
updated; 

d) Relevant analysis is developed; 

e) Corrective actions and improvement areas are 
established; 

f) Effectiveness and efficiency are improved; and 


g) Iteration alignment is improved. 


5.3.2.4 Program retrospective review practice 


The purpose of program retrospective practice is to 
evaluate the extent of value delivered over multiple 
releases and establish the way forward for the program. 
The program retrospective practice provides for 
self-reflection and causal analysis “in the way of 
working of the team” on a completed release and 
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establishes improvements and corrective actions on the 
way forward. Typical things that are considered include: 
past events, past situations, problematic scenarios, 
milestones, opinions, ideas, concerns, release backlog, 
product backlog, activities performed, impediments 
dealt, success stories, issues addressed, risks mitigated, 
priorities, accomplishments, constraints, assumptions, 
release goals, release schedule, and so on. 


5.3.2.4.1 Outcomes 


As a result of the successful implementation of the 
iteration review practice: 


a) Definition of ready and definition of done are 
updated; 

b) Product backlog, release backlog and improvement 
backlog are updated; 

c) Iteration and release plans are updated; 

d) Corrective actions and improvements are 
established; 

e) Plans to improve delivery efficiency is established; 

f) Continuous improvement areas are established; 
and 

g) Significant impediments addressed. 


5.3.2.5 Metrics governance practice 


The purpose of metrics governance practice is to gather 
metrics at various levels and use them to govern agile 
delivery by taking appropriate corrective actions. The 
metrics governance practice provides for definition, 
collection and analysis of metrics which can then be 
used to manage different aspects of the agile delivery. 
Typical things that are considered include: Quality 
metrics, business outcome metrics, agile maturity 
metrics, economic metrics, operational metrics, ROI, 
TOM, Cycle and lead time, post release defects, 
velocity, commitment adherence, backlog, de-scope 
index, retrospective index, automation coverage index, 
and so on. 


5.3.2.5.1 Outcomes 


As a result of the successful implementation of the 
metrics governance practice: 


a) Product backlog, iteration backlog, improvement 
backlog and release backlog are updated; 


b) Release plans and iteration plans are updated; 

c) Quality of delivery is improved; 

d) IT Operations and delivery is improved; 

e) Predictable delivery capability is developed; and 
f) Continuous improvement areas are established. 


5.3.2.6 Technical debt governance practice 


The purpose of technical debt governance is to monitor 
the consequences of software development actions 
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that inadvertently prioritize client value and project 
constraints over technical implementation and design 
considerations and resolve it amicably by appropriate 
refactoring. The technical debt governance practice 
provides for dealing with the consequences of software 
development actions that inadvertently result intechnical 
debt which needs to be dealt with appropriately in the 
later release cycles by means of appropriate refactoring 
or rework. Typical things that are considered include, 
domain and technical complexity, schedule slippages, 
capability and capacity of the team, conflicting user 
stories and features, cycle and lead time, pre-release 
defects, backlog, productivity, and so on. 


5.3.2.6.1 Outcomes 


As a result of the successful implementation of the 
technical debt governance practice: 


a) Product backlog, improvement backlog, release 
back and iteration backlog are updated: 


b) Corrective actions and decisions are undertaken; 
c) Technical debt for future releases is minimized; 
d) Technical debt accumulation is reduced, 

e) Cost of change is reduced; 

f) Quality of delivery is improved, and 

g) Technical management is improved. 


5.3.2.7 Program board governance practice 


The purpose of the program board governance is to 
manage the dependency of product backlog items across 
multiple agile teams. The Program board governance 
practice provides for governance of the technical, 
domain and functional dependencies items across 
multiple agile teams and enables agile teams to address 
these. Typical things that are considered include: 
Domain, technical and functional dependencies, 
resource dependencies, user stories and features, 
release plans, iteration plans, release schedule, iteration 
schedule, milestones, and so on. 


5.3.2.7.1 Outcomes 


As a result of the successful implementation of the 
program board governance practice: 


a) 


Program board and related dependencies are 
established: 


Corrective actions to resolve dependencies are 
established: 


Iteration plan, release plans and milestones are 
updated, 


b) 


c) 


Dependency related risks are mitigated; 
Domain dependencies are addressed; 
Technical dependencies are addressed; 
Functional dependencies are addressed; and 
Resource dependencies are addressed. 


5.3.2.8 Agile adoption maturity governance practice 


The purpose of agile adoption maturity governance 
practice is to manage the maturity of agile practices and 
their adoption by agile teams and enable continuous 
improvement. The agile adoption maturity governance 
practice provides for evaluation, management and 
improvement of the maturity of agile practices and 
their adoption by agile teams. Typical things that are 
considered include: Agile adoption strategies, agile 
adoption trends, observations, change management 
strategies, successful transformations, scalability 
of agile practices, progressive improvements, agile 
readiness assessments, agile practice maturity, agile 
maturity levels, agile measurement index, degrees of 
adoption, corrective actions, and so on. 


5.3.2.8.1 Outcomes 


As a result of the successful implementation of the 
agile adoption maturity governance practice: 


a) 


Agile adoption and scalability strategies are 
updated; 


Improvement plans are updated; 

Corrective actions are established; 
Predictability is increased; 

Organizations agile maturity level is increased; 


Business and delivery outcomes are improved; 
and 


g) Agile practices successfully implemented. 


5.3.2.9 Visual management practice 


The purpose of visual management practice is to provide 
ways and means to organize, manage and communicate 
large sets of information in simple and effective 
manner. The visual management practice provides for 
organization, management, and communication of large 
sets of information that are relevant for the different 
agile programs and projects. Typical things that are 
considered include: Work lists, status information, 
metrics and measures, iteration goals, release goals, 
dependencies, release plans, iteration plans, product 
backlog, release backlog, iteration backlog, and so on. 


5.3.2.9.1 Outcomes 


As a result of the successful implementation of the 
visual management practice: 


a) 
b) 


Dependencies are better managed; 

Impediments are addressed; 

The flow of work is improved; 

Different kinds of visualizations are established; 
Clarity of work status is improved; 

Work organization is improved; 


Transparency is improved; 
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h) Trust between teams and stakeholders 


improved; and 


are 


j) Efficiency of delivery is improved; 
5.3.2.10 Gemba 


The purpose of Gemba is to provide ways and 
means to observe the actual work processes, identify 
bottlenecks, and explore opportunities for continuous 
improvement. This includes leaders being in touch with 
the Agile team, observing their work and participating 
in Agile events, monitoring progress of work and 
providing feedback. The Gemba practice provides for 
observation, identification, analysis, and improvement 
of work processes for different agile programs and 
projects. Typical things that are considered include: 
Feedback, observations, discussions, activities 
performed, activities planned, work lists, metrics and 
measures, workspace issues, work processes, concerns, 
achievements, improvement efforts, and so on. 


5.3.2.10.1 Outcomes 


As a result of the successful implementation of the 
Gemba practice: 


a) Improvement plans and work processes are 
updated; 


Productivity is improved and cost reduced; 
Problems and opportunities are visible; 


Understanding of work and work processes is 
improved; 


Delays, waste, and issues are identified; and 
Work processes optimized. 


5.3.2.11 Distributed agile governance practice 


The purpose of distributed agile governance practice 
is to enable agile teams to self-organize, collaborate, 
and adapt to geographically distributed environments 
and deliver the desired value. The distributed agile 
governance practice provides ways and means for 
self-organization, collaboration, and adaptation to 
different environments to improve the efficiency of the 
agile teams. Typical things that are considered include: 
Communication barriers, time zone differences, 
cultural diversities, delays, impediments, alignment 
issues, lack of shared understanding, vision, Success 
parameters, definition of ready, definition of done, 
working agreement, feedbacks, retrospectives, and so 
on. 


5.3.2.11.1 Outcomes 


As a result of the successful implementation of the 
distributed agile governance practice: 


a) Shared vision and understanding is established; 
b) Sense of ownership is established; 
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Work processes are updated; 

Early detection of impediments; 

Increased business efficiency; 

Transparency is improved; 

Trust between distributed teams is improved; 
Delays are reduced; and 

Right skills and roles are utilized appropriately. 


5.4 Practices under Technical Processes 


These practices are concerned with the technical 
actions throughout the project lifecycle towards 
ensuring the project meets the needs and expectations 
of the stakeholders and achieves expected business 
outcomes. These practices transform the needs 
of stakeholders into a product or service. This 
sub-clause defines the requirements for the establishment 
of practices under Technical processes. The practices 
under technical processes relate to the technical effort 
of projects, to requirements definition, architecting and 
implementation. These practices are used in tandem 
with practices under technical management processes 
to achieve the desired solution attributes. 


The practices under technical processes consist of the 
following: 


a) Agile requirements management practices, 
b) Agile architecture practices, and 
c) Agile implementation practices. 


NOTE — The practices under Technical processes described 
in this document should be considered as an extension to the 
technical processes described in IS 16124 : 2020. 


5.4.1 Agile Requirement Management Practices 


The Agile requirement management practices are used 
to establish the requirements backlog and to ensure that 
the requirements backlog is addressed appropriately. 


The agile requirement management practices consist of 
the following: 


a) 
b) 
c) 


User stories practice; 

Product backlog elicitation practice; 
Product backlog refinement practice; 
User story mapping practice; 

Relative estimation practice; 

Active stakeholder participation practice; 
Deferred commitment practice; and 


h) Specification by example practice. 


5.4.1.1 User stories practice 


The purpose of user stories practice is to provide 
ways and means to gather desired requirements, 
functionalities, non-functional requirements, features, 
and capabilities from an end user point of view. The 
user stories practice provides for identification and 
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elicitation of requirements as user stories from an 
end-user perspective. Typical things that are 
considered include: user needs, user wants, value to 
end-users, software qualities, functional requirements, 
non-functional requirements, situation context, 
problem statements, difficulties, issues, risks, features, 
assumptions, constraints, and so on. 


5.4.1.1.1 Outcomes 


As a result of the successful implementation of the user 
stories practice: 


a) User stories are established; 

b) Requirements are clearly stated; 

c) Stated requirements are well understood; and 
d) Product backlog is updated. 


5.4.1.2 Product backlog elicitation practice 


The purpose of product backlog elicitation practice 
is to provide ways and means to gather and prioritize 
high level requirements, constraints, boundaries, high 
level objectives and work items. The product backlog 
elicitation practice is a continuous practice that 
provides for identification and elicitation of high-level 
requirements and objectives to arrive at the product 
backlog which is a living and evolving document. 
Typical things that are considered include: interface 


requirements, interaction requirements, domain 
requirements, functional requirements, non-functional 
requirements, work items, problems, difficulties, 


stakeholder concerns, technical tasks, process and 
related outcomes, scenarios and context, constraints, 
and so on. 


5.4.1.2.1 Outcomes 
As a result of the successful implementation of the 
product backlog elicitation practice: 
a) 
b) 


Use cases and usage scenarios are established; 


Multiple aspects 
understood; 


of business domain are 


Conflicting priorities are identified; 
Product backlog is established; and 


Priorities of business and other stakeholders are 
well understood. 


c) 
d) 


e) 


5.4.1.3 Product backlog refinement practice 


The purpose of the product backlog refinement practice 
is to refine, clean, review, clarify and prioritize product 
backlog items for the current scope of work. The 
product backlog refinement practice is a continuous 
practice that provides for refining, cleaning, reviewing, 
clarifying, and prioritizing product backlog items. 
Typical things that are considered include, vision, 
storyboards, personas, assumptions, acceptance criteria, 
market research, experiments, product backlog, and so 
on. 


5.4.1.3.1 Outcomes 


As a result of the successful implementation of the 
product backlog refinement practice: 


a) 
b) 
c) 


Scope of work and use cases are refined; 
Release goals and team plans are updated; 


Estimates for user stories, features and iteration 
goals are updated; 


Multiple aspects of business domain and 


immediate priorities are understood; 
Dependencies across agile teams are understood; 
Product backlog is refined; and 


Priorities of business and other stakeholders are 
well understood. 


5.4.1.4 User story mapping practice 


The purpose of the user story mapping practice is to 
facilitate the gathering, analysis, understanding and 
organizing requirements and managing their subsequent 
changes within a particular context and in prioritizing 
product delivery. The user story mapping practice 
provides the ways and means to develop views, identify 
dependencies, establish desired functionality, identify 
gaps, plan iterations and releases, and deliver value 
to stakeholders. Typical things that are considered 
include: Storyboards, personas, agile backlog, release 
backlog, user needs, user activities, user tasks, epics, 
user stories, features, journey maps, prioritizations, 
vision, user experience, and so on. 


5.4.1.4.1 Outcomes 


As a result of the successful implementation of the user 
story mapping practice: 


a) 
b) 
c) 


Journey maps and Product backlog is refined; 
Release plans is updated; 

Target outcomes and the corresponding impact is 
established; 

d) Relationships between user stories are established; 


e) Holistic understanding of the requirements 


becomes possible; 


f) 


g) 
h) 


Dependencies across agile teams are understood; 
agile backlog and release backlog are refined; and 


Interdependencies and potential risks are 


identified. 


5.4.1.5 Relative estimation practice 


The purpose of the relative estimation practice is to 
determine the estimates or measures for different 
entities relative to a point of reference. The relative 
estimation practice provides the ways and means of 
estimating or measuring different kinds of entities by 
determining the relative difference or scale from a point 
of reference. The relative estimation practice provides 
credible estimates to determine cost and effort, 
establish priorities and forecast a schedule. Typical 
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things that are considered include, user stories, epics, 
features, prior release metrics, prior iteration metrics, 
complexity, size, uncertainty, difficulties, impediments, 
constraints, reference information, known factors, 
unknown factors, changing requirements, capability 
and capacity of the team, dependencies, technical and 
domain readiness, maturity levels, and so on. 


5.4.1.5.1 Outcomes 


As a result of the successful implementation of the 
relative estimation practice: 


a) Knowledge about different aspects of the delivery 


is established; 
b) Release plan is updated; 
c) 
d) 


e) 


Realistic estimate of release effort is established; 
Realistic estimate of iteration effort is established; 


Ability to track progress of development is 
established; 


Complexity of user stories, epics and features is 
reduced; and 


f) 


g) Accuracy of estimation is improved. 


5.4.1.6 Active stakeholder participation practice 


The purpose of the active stakeholder participation 
practice is to establish the access, interaction and 
communication channels between stakeholders and 
agile teams. The active stakeholder participation 
practice provides the ways and means to ensure active 
involvement of stakeholders in the development and 
delivery of the product. This involves establishing the 
access to the stakeholders, establishing communication 
channels, and having continuous interactions with the 
stakeholders. Typical things that are considered include, 
communication channels, roles, responsibilities, user 
needs, user stories, skills and knowledge of the domain, 
perspectives and views, design principles, stakeholder 
concerns, features, epics, relationship, participation 
styles, interactions, location, communication channels, 
events, hand-offs, requisite inputs, feedback, and so on. 


5.4.1.6.1 Outcomes 


As a result of the successful implementation of the 
relative estimation practice: 

a) Openness is increased; 

b) Accountability is established; 

c) Degree of information exchange is established; 

d) Clarity on business needs and priorities is 
established; 


Effectiveness and impact of the release is 
increased; 


e) 


f) 


g) 
h) 


Quality of the deliverables are increased; 
Legitimacy of the decisions are improved; 


Coherence and consistency of the release is 
increased; 
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j) Wider participation is ensured; and 


k) Stakeholder engagement and interactions is 


ensured. 
5.4.2 Agile Architecture Practices 


The Agile architecture practices are used to establish 
the architecture and design of a system by providing a 
set of values, practices and collaborations. 


The agile architecture practices consist ofthe following: 
Initial architecture practice; 

Intentional architecture practice; 

Architecture description practice; 

Architecture runway practice; and 


Simple design practice. 


NOTE — The architecture practices described in this document 
should be considered as an extension to the architecture 
processes described in IS 16124 : 2020. 


5.4.2.1 Initial architecture practice 


The purpose of initial architecture practice is to 
establish the initial technical direction by providing 
high level architectural models and specifications. The 
initial architecture practice provides ways and means to 
establish the initial technical architecture to establish a 
technical strategy within the agile team and the various 
stakeholders. Typical things that are considered include, 
high level scope, business goals, business scenarios, 
initial requirements stack, architectural vision, product 
backlog, stakeholders, stakeholder concerns, situation 
context, constraints, assumptions, and so on. 


5.4.2.1.1 Outcomes 


As a result of the successful implementation of the 
initial architecture practice: 


a) Architecture strategy is established; 

Product backlog is improved; 

Architecture description artefacts are established; 
Architecture framework is established; 
Productivity is improved; 

Technical challenges are identified; 

Architecture vision and direction is established; 
Technical risk is reduced; 

Communication is improved; 

Team organization is improved; and 


Development time is reduced. 


5.4.2.2 Intentional architecture practice 


The purpose of intentional architecture practice is to 
define a set of purposeful architectural strategies and 
principles to enhance the design, performance, and 
usability of the solution. The intentional architecture 
practice provides ways and means to define a set of 
architectural strategies, principles, and directives to 
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enhance solution design, performance, extensibility, and 
usability by leveraging common architectural patterns, 
design constraints and implementation technologies. 
Typical things that are considered include, architectural 
strategy, design patterns, architecture frameworks, 
architecture vision, design principles and constraints, 
architecture styles, reference architectures, architecture 
models, stakeholder analysis, scenario analysis, 
requirements analysis, user behavioural insights, and 
so on. 


5.4.2.2.1 Outcomes 


As a result of the successful implementation of the 
intentional architecture practice: 


a) 


Architecture related artefacts, architecture vision 
and strategy are updated; 


b) 
c) 


Product backlog is updated; 


The problem being addressed is clearly defined 
and understood; 

d) The potential solutions are clearly defined and 
understood; 

e) The architecture’s key concepts, properties, and 
principles are clearly defined; and 


f) 


The architecture is clearly conceived and key 
trade-offs are understood. 


5.4.2.3 Architecture description practice 


The purpose of architecture description practice is to 
define the representation of the solution in a form that 
provides the ability to portray, understand or predict 
the solution characteristics under certain situations 
of interest. The architecture description practice 
provides ways and means to establish a representation 
of an architecture to illustrate a specific set of 
information items that are relevant to the agile teams 
and stakeholders. Typical things that are considered 
include: architecture concepts, solution characteristics, 
solution components, functional requirements, 
non-functional requirements, product backlog, user 
stories, features, capabilities, capacities, resources, 
architecture decisions, architecture rationale, solution 
concepts, architecture principles, architecture views, 
inherent processes, design patterns, interfaces, 
architecture approaches, modelling languages, 
meta-models, and so on. 

NOTE — The architecture description practices described in 

this document should be considered as an extension to the 


architecture elaboration processes described in IS 16124 : 2020 
and ISO/IEC/IEEE 42020 : 2019. 


5.4.2.3.1 Outcomes 


As a result of the successful implementation of the 
architecture description practice: 


a) System structure and behaviour is visualized, 
b) System complexity is understood, 
c) System dependencies are exposed, 


d) Architecture is amenable for analysis; 
e) Risks management is improved; and 


f) Architecture decisions are documented. 


5.4.2.4 Architectural runway practice 


The purpose of architectural runway is to establish 
necessary technical infrastructure to implement new 
features and capabilities without extensive redesign 
and delay thereby ensuring the overall velocity. The 
architectural runway practice provides ways and means 
to establish a technical infrastructure for implementing 
new features and capabilities with minimal or no change 
in the existing architecture or agile environment. 
The objective is to extend the architecture as and 
when necessary. Typical things that are considered 
include, new features, change requirements, new user 
stories, new epics, new solution characteristics, new 
architecture principles, new scenarios, frequency 
of change, available enablers, value created, value 
destructed, velocity, and so on. 


5.4.2.4.1 Outcomes 


As a result of the successful implementation of the 
architectural runway practice: 


a) 
b) 


Architecture runway enablers are established, 


Architecture artefacts and fundamental concepts 
are established: 


Product backlog is updated; 
Continuous delivery pipeline is established: 


Ability to respond to business challenges is 
increased; 


Time to market is shorter and faster; 
Technical debt is reduced; 
Velocity is sustained; 


Application performance and stability is increased; 
and 


k) Economic outcomes are improved. 


5.4.2.5 Simple design practice 


The purpose of simple design practice is to keep 
things, as simple as possible, while addressing current 
requirements and moving forward with least resistance. 
The simple design practice provides ways and means to 
keep the design and architecture ofthe solution as simple 
and as relevant as possible to the current requirements 
so that the iteration and release can move forward with 
least resistance. The objective is to extend the design as 
and when necessary. Typical things that are considered 
include, product backlog, iteration backlog, release 
backlog, solution characteristics, solution design, 
design flaws, design decisions, core concepts, design 
decisions, new features, change requirements, new user 
stories, new epics, new solution characteristics, new 
architecture principles, new scenarios, and so on. 
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5.4.2.5.1 Outcomes 


As a result of the successful implementation of the 
simple design practice: 


a) System design and its architecture description are 
updated; 

b) Architecture decisions, rationale, capabilities and 
features are updated; 

c) Risk due to overdesign is mitigated; 

d) Design flaws are identified and fixed; 

e) Cost is reduced; 

f) Flexibility to make changes is improved; 

g) Maintenance is improved; and, 

h) System design is minimalistic. 


5.4.3 Agile Implementation Practices 


The Agile implementation practices are used to 
transform requirements, architecture and design into 
a product increment or software element that leads 
towards a product increment. 


The agile implementation practices consist of the 
following: 


Test driven development practice; 
Acceptance test driven development practice; 
Behaviour driven development practice; 
Feature driven development practice; 
Agile testing pyramid practice; 
Continuous integration practice; 
Continuous deployment practice; 
Continuous delivery practice; 
Continuous documentation practice; 
Lean documentation practice; 

Clean code practice; 

Feature toggles practice; and 
Refactoring practice. 


NOTE — The agile implementation practices described in 
this document should be considered as an extension to the 
implementation processes described in IS 16124 : 2020. 


5.4.3.1 Test driven development practice 


The purpose of test-driven development practice is to 
evolve towards a clearer, simpler and bug-free code. 
The test-driven development practice provides for 
establishing tests before the actual implementation 
of the related parts of the system. Typical things to 
be considered include, functionality, user stories, 
features, change requirements, epics, unit tests, testing 
frameworks, test cases, and so on. 


5.4.3.1.1 Outcomes 


As a result of the successful implementation of the 
test-driven development practice: 


a) Automated tests are performed and test results 
gathered; 
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b) Test configurations, frameworks and strategy are 
updated; 

c) 

d) 


Debugging effort is reduced; 
Development effort is reduced; 
Defects are reduced; 


More effective and sustainable testing strategy 
and implementation; 


Code is modularized, flexible and extensible; 
Code quality is enhanced; and 
Time to market is improved 


5.4.3.2 Acceptance test driven development practice 


The purpose of acceptance test-driven development 
practice is to evolve towards a software that addresses 
the specified acceptance criteria. The acceptance 
test-driven development practice provides for 
establishing acceptance tests before the actual 
implementation of the related system. Typical things to 
be considered include, functionality, desired behavior, 
user stories, acceptance criteria, features, change 
requirements, epics, unit tests, testing frameworks, test 
cases, and so on. 


5.4.3.2.1 Outcomes 


As a result of the successful implementation of the 
acceptance test-driven development practice: 


a) Debugging effort is reduced; 


b) Test configuration is updated; 
c) 


Automated tests are performed and test results 
gathered; 


Defects are reduced; 
e) 


More effective and sustainable testing strategy 
and implementation; 


Code is modularized, flexible and extensible; 
Code quality is enhanced; 
Time to market is improved; and 


Customer engagement is enhanced. 


5.4.3.3 Behavior driven development practice 


The purpose of behavior driven development (BDD) 
practice is to evolve towards a software that achieves 
the specified system behavior. The behavior driven 
development practice provides for establishing 
tests before the actual implementation of the related 
behavior of the system. Typical things to be considered 
include: functionality, system behavior, key scenarios, 
shared vocabulary, acceptance criteria, user stories, 
features, change requirements, epics, unit tests, testing 
frameworks, test cases, and so on. 


5.4.3.3.1 Outcomes 


As a result of the successful implementation of the 
behaviour driven development practice: 


a) Automated tests are performed, and test results 
gathered; 
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Test configuration is updated; 
Debugging effort is reduced; 
Development effort is reduced; 
Defects are reduced; 


More effective and sustainable testing strategy 
and implementation; 


Code is modularized, flexible and extensible; 
Code quality is enhanced; 

Time to market is improved; and 

Customer engagement is enhanced. 


5.4.3.4 Feature driven development practice 


The purpose of feature driven development practice is 
to deliver tangible, working software repeatedly in a 
timely manner in accordance with the agile principles. 
The feature driven development practice provides 
for establishing, managing, and developing feature 
sets comprising features that deliver business value 
with minimum effort. Typical things to be considered 
include, functionalities, capabilities, feature sets, 
features, user stories, change requirements, roles and 
responsibilities, inspections, feature models, use cases, 
data structures, interfaces, priorities, epics, and so on. 


5.4.3.4.1 Outcomes 


As a result of the successful implementation of the 
feature driven development practice: 


a) Definition of ready and definition of done is 
updated; 


Architecture and technical design are updated; 
Debugging effort is reduced; 

Development effort is reduced; 

Defects are reduced; 


More effective and sustainable testing strategy 
and implementation; 


Code is modularized, flexible and extensible; 
Code quality is enhanced; 

Time to market is improved; and 

Customer engagement is enhanced. 


5.4.3.5 Agile testing pyramid practice 


The purpose of agile testing pyramid practice is to 
establish the testing strategy for agile development. 
The agile testing pyramid practice provides for 
establishing, managing, and developing test strategies 
and test automation strategies for agile development 
with minimum effort. Typical things to be considered 
include, testing frameworks, unit tests, acceptance 
tests, component tests, user interface tests, behavior 
tests, manual tests, defects, test cases, automation 
frameworks, and so on. 


5.4.3.5.1 Outcomes 


As a result of the successful implementation of the 
agile testing pyramid practice: 


Testing strategy is updated; 
Test configurations are updated; 
Debugging effort is reduced; 
Development effort is reduced; 
Defects are reduced; 


More effective and sustainable testing strategy 
and implementation; 


Code is modularized, flexible and extensible; 
Code quality is enhanced; 

Time to market is improved; and 

Customer engagement is enhanced. 


5.4.3.6 Continuous integration practice 


The purpose of continuous integration practice is to 
establish the integration strategy for agile development. 
The continuous integration practice provides for 
establishing, managing, and developing system 
integration strategies for agile development. Typical 
things to be considered include: integration frameworks, 


integration tools, acceptance tests, components, 
interfaces, use cases, underlying technologies, 
check-in policies, build management policies, 


development environments, third party components, 
self-testing, testing environment, test cases, automation 
frameworks, and so on. 


5.4.3.6.1 Outcomes 


As a result of the successful implementation of the 
continuous integration practice: 


a) 
b) 
c) 


Test configurations are updated; 

Testing strategies are updated; 

Integration effort is reduced; 

Debugging effort is reduced; 

Downstream integration defects are reduced; 
Branches and diversions are eliminated; 
Build overhead is reduced; 

transparency around code is increased; 

code versioning is improved; and 

Overall efficiency is improved. 


5.4.3.7 Continuous deployment practice 


The purpose of continuous deployment practice 
is to establish the deployment strategy for agile 
development. The continuous deployment practice 
provides for establishing, managing, and developing 
system deployment strategies for agile development. 
Typical things to be considered include, deployment 
frameworks, deployment tools, components, services, 
interfaces, packages, target environment, third party 
components, self-testing, automation frameworks, 
deployable artefacts, and so on. 


5.4.3.7.1 Outcomes 


As a result of the successful implementation of the 
continuous deployment practice: 
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Test configurations are updated; 
Testing strategies are updated; 
Deployment effort is reduced; 

Lead time is reduced; 

Return on investment is realized; 
Deployment overhead is reduced; and 


g) Overall efficiency is improved. 


5.4.3.8 Continuous delivery practice 


The purpose of continuous delivery practice is to 
establish the ready for release and subsequent manual 
deployment strategy for agile development. The 
continuous delivery practice provides for establishing, 
managing, and developing system release strategies 
for agile development. Typical things to be considered 
include, development environments, version control, 
automation frameworks, change requests, new user 
stories, new features, new epics, bug fixes, experiments, 
configuration changes, release strategy, deployment 
pipeline, acceptance tests, and so on. 


5.4.3.8.1 Outcomes 


As a result of the successful implementation of the 
continuous delivery practice: 


a) 
b) 
c) 
d) 


Implementation strategies are updated; 
Overall effort is reduced; 

Delivery costs are lowered; 

Lead time is reduced; 

Return on investment is realized; 
Improved productivity and efficiency; 
Improved product quality; 

Improved customer satisfaction; and 
Accelerated time to market. 


5.4.3.9 Continuous documentation practice 


The purpose of continuous documentation practice 
is to establish the documentation strategy for agile 
development. The continuous documentation practice 
provides for establishing, managing, and developing 
documentation strategies for agile development. 
Typical things to be considered include, release 
artefacts, deployable artefacts, integration artefacts, 
code, configuration management information, test 
results, use cases, test cases, user stories, features, 
requirements, epics, change requirements, structured 
information, unstructured information, information 
sources, repository, and so on. 


5.4.3.9.1 Outcomes 


As a result of the successful implementation of the 
continuous documentation practice: 


a) Documentation strategy is updated; 
b) System documentation is updated; 
c) Delivery risk is mitigated; 
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d) Accuracy risk is mitigated; 
e) Artefacts are up to date; and 
f) Lead time is reduced. 


5.4.3.10 Lean documentation practice 


The purpose of lean documentation practice is to 
eliminate waste due to documentation. The lean 
documentation practice provides for establishing, 
managing, and developing documentation for relevant 
stakeholders. Typical things to be considered include, 
release artefacts, deployable artefacts, integration 
artefacts, code, configuration management information, 
test results, use cases, test cases, user stories, features, 
requirements, epics, change requirements, structured 
information, unstructured information, information 
sources, repository, value adding activities, non-value 
adding activities, and so on. 


5.4.3.10.1 Outcomes 


As a result of the successful implementation of the lean 
documentation practice: 


a) Documentation strategy is updated; 

b) Documentation activities are updated; 

c) System documentation is updated; 

d) Documentation requirements are addressed; 
e) Documentation is simplified; 

f) Communication is improved; 

g) Relevant documents are developed; and 

h) Waste due to documentation is reduced. 


5.4.3.11 Clean code practice 


The purpose of the clean code practice is to establish 
the development and maintenance strategy for agile 
development. The clean code practice provides for 
establishing development and maintenance strategy 
for code. Typical things to be considered include 
code, coding standards, coding guidelines, use cases, 
test cases, user stories, features, requirements, epics, 
change requirements, information sources, repository, 
and so on. 


5.4.3.11.1 Outcomes 


As a result of the successful implementation of the 
clean code practice: 


a) Code is refactored; 

b) Code quality is improved; 

c) Technical debt is reduced; 

d) Delivery outcomes are improved; 
e) Code is clean and simple; 


f) Code is consistent and coherent; and 
g) Maintenance cost is reduced. 


5.4.3.12 Feature toggles practice 


The purpose of feature toggle practice is to establish 
ways and means of reducing feature branches. The 
features toggle practice provides for establishing, 
managing, and developing strategies for dealing with 
feature branches. Typical things to be considered include 
features set, user stories, epics, customizations, feature 
groups, integration frameworks, integration tools, 
toggle rules, interfaces, components, functionalities, 
services, and so on. 


NOTE — Feature toggles are also referred as feature flags. 


5.4.3.12.1 Outcomes 
As a result of the successful implementation of the 
feature toggles practice: 

a) Code repository and test configurations are 

updated; 

b) Feature branches are reduced; 

c) Branching risk is mitigated; 

d) Merging changes across branches is removed; 

e) Dead code is reduced; and 

f) Dynamic extensibility is provisioned. 


5.4.3.13 Refactoring practice 


The purpose of refactoring practice is to improve 
the internal structure of an existing software, while 
preserving its behavior. The purpose of refactoring 
practice is to provide ways and means for dealing with 
the degradation in software and improving the ability to 
maintain and extend the software. Typical things to be 
considered include, functionalities, features, external 
behavior, services, interfaces, responses, interactions, 
interfaces, risks, user stories, test cases, use cases, 
system qualities, and so on. 


5.4.3.13.1 Outcomes 


As a result of the successful implementation of the 
clean code practice: 


a) Code is refactored; 

b) Code quality is improved; 

c) Technical debt is reduced; 

d) Delivery outcomes are improved; 

e) Code is clean and simple; 

f) Code is consistent and coherent; and 
g) Maintenance cost is reduced. 
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ANNEX A 
( Clause 2 ) 
LIST OF REFFERED INDIAN STANDARDS 


IS No. Title 


16124 : 2020/ISO/IEC/IEEE 12207 : 2017 Systems and software engineering — Software life 
cycle processes 


ANNEXB 
( Foreword, Clause 2 ) 
LIST OF REFFERED INTERNATIONAL STANDARDS/PUBLICATIONS 


International Title International Title 
Standards/Other Standar ds/ Other 
Publication Publication 

ISO/IEC/IEEE 24765 Systems and software BO IEC/IEEE 42020 Software, systems and 

- 2017 engineering — Vocabulary :2019 enterprises — Architecture 

processes 

ISO/IEC/IEEE 26515 Systems and software 

:2018 engineering — Developing 


information for users in an 
agile environment 
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